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(54) Enhanced transport of ethernet traffic over a transport SDH/SONET network 



(57) Disclosed is a method and device for handling 
Ethernet frame signals in a SDH/SONET network, the 
SDH/SONET network comprising network elements or 
nodes and fiber connections connecting the network el- 
ements, the method being characterized by the step of 
defining a new layer/network overthe SDH/SONET net- 
work in order to manage the Ethernet signals over the 
SDH/SONET network, the new layer/network using the 
resources of SDH/SONET network in such a way as to 
optimize the provided services and the performances 
with reference to th is specific type of transport. The step 



of defining a new layer/network comprises the steps of: 
defining at least two Ethernet Access Points, namely 
Ethernet interfaces at the SDH/SONET network bound- 
ary where the Ethernet signals can access/leave the 
SDH/SONET network; defining a Link as a pair of Eth- 
ernet Access Points providing a point-to-point connec- 
tion; for any pair of Ethernet Access Points, defining cor- 
responding Circuits, namely all the possible routes con- 
necting the pair of Access Points through the SDH/SON- 
ET network; and dividing each Circuit into Pipes, namely 
a sequence of smaller segments. 
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Description 

[0001] The present invention relates to the telecommunication field and in particular to a method and device for 
managing Ethernet frame traffic and transporting such a traffic over a transport SDH/SONET network. 

5 [0002] As it is known, traffic generated by an Ethernet apparatus is characterized by discontinuities, namely there 
are periods with a more or less constant sending rate of Ethernet packets and periods during which a rather long time 
is provided between a received Ethernet frame and the next one. Such an unstable/inconstant traffic is generally termed 
"bursty". On the contrary, SDH or SONET traffic is characterized by a constant sending/receiving rate. In other words, 
any network element of a transport SDH/SONET network sends corresponding frames with a regular and constant 

10 rate. Furthermore, Ethernet frames do not have a fixed length/size but only a maximum size (1518 bytes). 

[0003] It is easy to understand that these discrepancies result in a highly difficult interfacing of two technologies 
having different natures/characteristics. 

[0004] An already available solution to the above problem allows the mapping of Ethernet frames into SDH/SONET 
Virtual Containers as a transparent tributary; all incoming bits are transported to the output interface with the related 
15 timing information (frequency for recovering the proper bit rate at the reception side). Within the SDH/SONET payload 
also the dead times between a received Ethernet frame and the following one are mapped. 

[0005] Unfortunately, while such a solution could be considered easy to be implemented, the performances of this 
type of transport are the same as for the transport of a PDH tributary, namely rather low. This best prior solution is 
strictly tied to SDH architecture and it does not allow to provide new services or to achieve better performances with 
20 respect to the transport of a transparent PDH tributary. Furthermore, some bandwidth is wasted because it is used for 
transporting useless information. 

[0006] In view of the above problems, the general object of the present invention is overcoming them in an efficient 
manner. 

[0007] The main scope of the present invention is providing a method and device for an enhanced transport of 

25 Ethernet frame traffic over a transport SDH/SONET network. 

[0008] The above and further objects of the present invention are obtained by a method and device according to 
claims 1 and 9, respectively. The present invention further comprises a network manager according to claim 8. Further 
advantageous features of the present invention are set forth in respective dependent claims. All the claims are intended 
as an integral part of the present description. 

30 [0009] The basic idea of the proposed solution is to provide a complete new layer/network over the SDH/SONET 
network in order to manage the transport of Ethernet traffic over SDH/SONET network; this new layer/network uses 
the resources of SDH/SONET network in such a way as to optimize the provided services and the performances with 
reference to this specific type of transport. 

[0010] The device according to the present invention is able to monitor continuously the Ethernet channel and to 
35 distinguish the nature of Carrier Event, so that the frames containing payload can be selected and the idle ones can 
be disregarded and not mapped in SDH virtual containers. 

[001 1] In orderto increasethe interfacing between Ethernet and SDH/SONET and better supporting all functionalities 
to be implemented, it has been decided to insert a further level of data encapsulation. 

[0012] The present solution allows Ethernet clients to set-up their own Virtual Private Networks (based on point-to- 
40 point connections) by means of SDH/SONET network. 

[0013] The present invention will become clear in view of the following detailed description, to be read having refer- 
ence to the attached sheets of drawings, wherein: 

Fig. 1 shows the structure of a VPN and relating circuits; 
45 - Fig. 2 is a schematic representation of encapsulation step of Ethernet frames into a SDH/SONET frame; 
Fig. 3 shows a basic scheme of insertion of GFP packets into C-4 containers; and 
Fig. 4 shows in better detail a selected Link with the two related Circuits. 

[0014] The present invention is implemented by providing a complete new layer/network which is termed NETS (i. 
50 e. Network of Ethernet Transport over SDH/SONET). The NETS comprises basic elements to be defined herebelow. 
[0015] The basic resources of NETS are the SDH/SONET Virtual Containers; the NETS uses these resources as 
basic pipelines to connect two Ethernet access points (point to point connection). 

[0016] The NETS model provides different schemes of connection and management of these basic pipelines; by 
means of this new model it is possible to provide new services and to perform, in a better way, services already provided 
55 by SDH/SONET network. 

[0017] The NETS model is based on five basic elements: Access Point, Link, Circuit, Pipe and Path. 

[0018] An Access Point (AP) is an Ethernet interface at the boundary of an SDH/SONET network; it is the point 

where the Ethernet traffic can access/leave the SDH/SONET network. 
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[0019] Fig. 1 depicts a simple example of network comprising six Network Elements (NE) with each network element 
having an Access Point; naturally, a Network Element can host more than one Access Point. 

[0020] Only the Network Elements with capability to drop/insert Ethernet traffic are depicted; Network Elements that 
just manage SDH/SONET traffic are transparent and are not depicted. 
5 [0021] A pair of Ethernet Access Points defines a point to point connection; this connection is named Link. For 
instance, with reference to Fig. 1 , the pair AP #0 & AP #1 identifies a link; the couple AP #2 & AP #5 defines another 
link, and so on. 

[0022] In case two access points are connected to a single link, such a link represents a Point-to-Point connection. 
Should an access point be connected to more than one link, such an access point is subject to a Point-to-multiPoint 
10 connection but the various links are to be considered Point-to-Point connections. In case of multipoint connections, 
dispatching (sending different frames to several APs) and grooming (aggregations of frames coming from several APs) 
functionalities should be provided. 

[0023] An SDH/SONET network could allow for the connection of two Access Points (i.e. to accomplish a Link) by 
means of different routes; every route is named Circuit. A Circuit is obtained by a Pipe concatenation and could be 
*5 considered as a series connection of N Pipes. 

[0024] The following Table 1 lists the possible routes for the Link identified by the Access Points AP #0 & AP #1 in 
Fig. 1. 



Table 1 



20 



25 



LINK 


RELATED CIRCUITS 


AP#0 - AP#1 


NE#0-NE#1 


NE#0-NE#4-NE#1 


NE#0-NE#3-NE#4-NE#1 


NE#0-NE#3-NE#2-NE#1 


NE #0 - NE #4 - NE #3 - NE#2 - NE #1 



[0025] In principle, also route NE #0 - NE #4 - NE #3 - NE #0 - NE #1 is possible but it is not really significant because 
it is made up by a ring that leads to the starting point NE #0 and route #1 . 

[0026] Link AP #0 - AP #1 is accomplished by means of these five circuits; of course a subset of all possible Circuits 
could be selected to accomplish a Link. 

[0027] In its turn, every Circuit/route that connects two Access Points can be divided into a sequence of smaller 
segments; every segment is named Pipe. 

[0028] With reference to the previous list of Circuits, in Table 2 is the description of all the related Pipes. 



Table 2 





LINK 


RELATED CIRCUITS 


RELATED PIPES 


40 


AP #0 - AP #1 


NE#0-NE#1 


NE #0 - NE # 1 






NE#0-NE#4-NE#1 


NE #0 - NE#4 








NE#4-NE#1 


45 




NE#0-NE#3-NE#4-NE#1 


NE #0 - NE #3 








NE#3- NE#4 








NE#4- NE#1 






NE#0-NE#3-NE#2-NE#1 


NE#0- NE#3 


50 






NE#3- NE#2 








NE#2- NE#1 






NE #0 - NE #4 - NE #3 - NE#2 - NE #1 


NE#0- NE#4 


55 






NE#4- NE#3 








NE #3 - NE#2 








NE#2-NE#1 
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[0029] As it is clear from the above Table 2, a Pipe can be shared among different Circuits. 

[0030] In its turn, every Pipe comprises one or more SDH/SONET Virtual Containers; this means that its capability 
is the sum of the capabilities of all the related Virtual Containers. 

[0031] Here below (see Table 3), with reference again to Figure 1 , is a complete Link description with the Pipe 
5 composition. 



Table 3 





LINK 


RELATED CIRCUITS 


RELATED PIPES 


PIPE COMPOSITION 


10 


AP#0- AP#1 


NE#0-NE#1 


NE#0-NE#1 


5 x VC - 1 2 






NE#0-NE#4-NE#1 


NE#0- NE#4 


1 VC-3 








NE#4-NE#1 


10 x VC-12 


15 




NE#0-NE#3-NE#4-NE#1 


NE #0 - NE #3 


3 x VC-12 






NE#3-NE#4 


1 VC-3 








NE#4-NE#1 


10 x VC-12 






NE#0-NE#3-NE#2-NE#1 


NE #0 - NE #3 


3xVC-12 


20 






NE#3-NE#2 


1 VC-3 








NE#2-NE#1 


5 x VC-12 






NE #0 - NE #4 - NE #3 - NE#2 - NE #1 


NE#0 - NE#4 


1 VC-3 


25 






NE#4-NE#3 


1 VC-3 






NE #3 - NE#2 


1 Vc-3 








NE#2-NE#1 


5 x VC-12 



[0032] The basic pipeline is the Virtual Container that connects two Network Elements; it is named Path. 
[0033] In order to improve the interfacing between Ethernet and SDH/SONET, and for better supporting all the func- 
tionalities that have been selected, it has been decided to insert a further level of data encapsulation. The protocol 
used for this intermediate level is GFP (Generic Frame Procedure). This technique has been selected because GFP 
packet has been properly defined for allowing the mapping of generic data in transport frames having variable-length 
payload and based on octet alignment, such as SDH/SONET and OTN (Optical Transport Network). Fig. 3 shows a 
basic scheme of data encapsulation according to the present invention. 

[0034] From the figure one can infer that the first encapsulation stage has a 1 :1 rate (an Ethernet message is inserted 
in a GFP message). As far as the mapping of GFP packets into SDH/SONET Virtual Containers is concerned, such a 
mapping is accomplished by a method similar to the one used for mapping ATM frames. In order to facilitate the 
comprehension of such a procedure, it is possible to consider the GFP packets as a byte stream to be inserted into 
Virtual Containers. The number of GFP packets that could be inserted into a VC is variable and depends on two 
fundamental factors: the VC capacity and the GFP dimension which in turn depends on the Ethernet frame to be 
transported. 

[0035] According to these two factors, it is possible that a single GFP packet is mapped into two or more Virtual 
containers or that a plurality of GFP packets is inserted into a single VC. 

[0036] In order to recover the GFP frames, it is necessary to perform an alignment to PLI field, which in turn indicates 
the length of payload data field. The PLI (PDU Length Indication) field will be disclosed below. Some examples of GFP- 
to-VC-x mapping are also reported below. 

[0037] In PLI field there are provided two octets. They are the binary number representing the number of octets 
contained into the payload area of the packet itself. 

[0038] The monitor information for managing the network according to the present invention are exchanged through 
the use of proper Scout Message GFP packets. They are control packets that are always sent before sending single 
packets containing Ethernet frames (in principle, a proper scout message alone is sent in case there are no messages 
to be transported). 

[0039] Four different scout messages are provided according to the present invention. In principle, each different 
scout message covers a portion of the information that is requested by the network that is realized in accordance with 
the present invention. Conveniently, each Scout Message comprises a SMT (Scout Message Type) field for clearly 
indicating the type of scout message (for instance: STM for Path Status Message = 00; STM for Complete Status 
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Message = 01 ; STM for Complete Status and Ethernet Message Info = 02 and STM for Complete Status and Delay 
Message = 03) . 

[0040] The first and simpler Scout Message that is provided is termed Path Status Message. It is able to report only 
the information relating to the path operation condition. 
5 [0041] The second Scout Message, termed Complete Status Message, contains all the information required for cal- 
culating an estimation of delays of data propagation through the virtual private network and the information relating to 
the operation status of Links, Circuits and Paths. 

[0042] The third Scout Message, termed Complete Status and Ethernet Message Info, is put before the G FP message 
containing the Ethernet frame. The object of such a packet is to transport all the information relating to the operation 
10 status, those information requiredforcalculatingthetransittimeof packets andthose information relatingtothe Ethernet 
message that is transported. 

[0043] The fourth Scout Message, termed Complete Status and Delay Message, is very similar to the third one but 
the difference is in that it is sent without a GFP packet containing an Ethernet frame. The object of such a Scout 
Message is to provide useful indications about transit times of Circuits of a Link even if there are no Ethernet frames 
*5 to be sent. Just for this reason, all the fields containing information relating to the data message are not significant; 
only the fields transporting the Path status, the Circuit status, Link status and their delays are considered as valid. 
[0044] There now follow some examples of mapping Ethernet frames into SDH structures. The very same concepts 
are equally applicable to SONET structures. 

[0045] In order to better understand the mapping procedure according to the present invention, the following basic 
20 notions and new concepts are set forth. 

Capacity C-4: 2340 bytes 
Capacity C-12: 136 bytes 
Capacity C-3: 756 bytes 
25 Max size of Ethernet frames: 1 51 8 bytes + 8 bytes (preamble + SDF) 

Size of additional GFP fields for an Ethernet frame: 12 bytes 
Size of Scout Message Complete Status and Ethernet Message Info: 20 bytes 
Size of Scout Message Complete Status Message: 18 bytes 

30 [0046] First Example: mapping a 1 526-byte Ethernet frame, together with an accompanying Scout Message, into i) 
a VC-4, ii) a VC-3 or iii) VC-12. The accompanying Scout Message is Complete Status and Ethernet Message Info. 
Within the GFP packet encapsulating the Ethernet Frame, the Preamble and SFD (Start Frame Delimiter) fields of the 
Ethernet frame should not be included; thus, in the Payload Data field of GFP, 1518 bytes are inserted. As the Scout 
Message size is 20 bytes, 1550 bytes are inserted into the SDH frame payload. 

35 

i) Mapping into a VC-4: a C-4 container has 2340 bytes and thus it is possible to insert only the Ethernet message 
together with the respective Scout Message (2340 bytes / 1 550 bytes = 1 ,509). In case two Ethernet frames should 
be transported, it is clear that the second Ethernet frame and its Scout Message can be only partially inserted in 
the first container while the remaining bytes should be mapped into the second C-4 (see Fig. 3). 
40 jj) Mapping into a C-3: a C-3 container has 756 bytes and thus three C-3 containers should be used for inserting 

an Ethernet frame. Two containers will be completely filled while the third one will be only partially used. 

iii) Mapping into a C-12: a C-12 has 136 bytes and thus twelve C-12 containers should be used for inserting an 
Ethernet frame. Eleven containers will be completely filled while the last one will be only partially used. 

45 [0047] Second Example: mapping a 1 8-bytes Complete Status Message into iv) C-4, v) C-3 and vi) C-12. 

iv) Mapping into a VC-4: a C-4 container has 2340 bytes and thus it is possible to insert 130 Complete Status 
Messages. 

v) Mapping into a C-3: a C-3 container has 756 bytes and thus it is possible to insert 42 Complete Status Messages. 
50 vi) Mapping into a C-12: a C-12 has 136 bytes and thus seven Complete Status Messages could be inserted, with 

a further Complete Status Message being partially inserted. 

[0048] Naturally, the above calculations are purely theoretic, as the size of an Ethernet frame does not always cor- 
respond to the admissible maximum size. 
55 [0049] A point-to-point connection of two Access Points is accomplished by the following steps: 

a) Defining a Link; 

b) Selecting one or more Circuit(s); 
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c) Defining the size of the related Pipes; and 

d) Selecting the related Paths. 

As now the point-to-point connection is fully defined, the simple transport of an Ethernet frame is performed 
by the following steps: 
5 e) Receiving the Ethernet frame at the Ethernet interface of one Access Point; 

f) Routing the Ethernet frame to at least one link; 

g) Selecting one of the available Circuits; 

h) Selecting one available Path of the (first) Pipe of the selected Circuit; 

i) Encapsulating the Ethernet frame into the selected available Path (i.e. Virtual Container); 

10 j) Transporting the Ethernet frame up to the next Network Element (namely, up to the end of the Pipe); and 

k) Extracting the Ethernet frame from the Virtual Container. 

[0050] In case the selected Circuit comprises further Pipes, steps h) to k) are repeated in every intermediate Network 
Element until the last Network Element is reached. Furthermore 

15 

I) Inserting the extracted Ethernet frame in a re-ordered queue. In fact, due to the possible skew among different 
Circuits or among the different Paths of a Pipe, the order of the messages received at the destination Network 
Element could be different from the order of the messages at the starting Access Point, so a re-ordering action is 
required. Should just one Circuit and simple Paths be used, step k) is not required. 
20 m) Finally, providing the Ethernet frame to the Ethernet interface of the destination AP. 

[0051] The above is just an example of simple transport for showing the versatility of the additional network/layer 
according to the present invention. Herebelow is a detailed description of an Ethernet hitless protection performed 
through the present invention. In principle, SDH/SONET networks already provide different types of protection (for 
25 instance SNCP or MS-SPRING) that can be applied to Ethernet frames as Ethernet frames are encapsulated into SDH/ 
SONET Virtual Containers. The advantage of the Ethernet hitless protection mechanism according to the present 
invention is that it is performed atthe lower possible level, it could be easily hardware implemented and provides hitless 
performances. 

[0052] With reference to Fig. 1 , let consider the point-to-point connection (Link AP #0 - AP #1 ) which is identified by 
30 the pair of Access Points AP #0 and AP #1 . Different routes made up by SDH/SONET Virtual Containers can connect 
the two Access Points AP #0 and AP #1 ; for instance, two of them could be Circuit A and Circuit B. Circuit A is the 
direct route comprising five VC-12; Circuit B is a route comprising a sequence of one VC-3 and ten VC-12 with an 
intermediate node (NE #4). In principle, several other routes can connect the two Access Points AP #0 and AP #1 but 
for the aim of this example and for clarity reasons just two of them will suffice. 
35 [0053] Fig. 5 highlights the selected Link with the two related Circuits. 

[0054] The basic idea of the proposed solution comprises the following steps: 

□ Every time an Ethernet frame is received at AP #0 of NE #0 it is transmitted along both Circuit A and Circuit B. 
Clearly, the transmission along two different routes results in a protection service. 

40 □ As a consequence of the previous step, NE #1 receives the same Ethernet frame twice; as a rule, it will accept 
the frame received from the faster Circuit and discharges the second one. Let consider Circuit B is faster than 
Circuit A; Ethernet frames received from Circuit B are selected while the frames received from Circuit A are dis- 
charged. 

□ In case of failure of Circuit B, NE #1 just receives frames from Circuit A and of course accepts them; the protection 
45 is accomplished by changing the selection of the Circuit from B to A. 

[0055] The protection is hitless because the selection is frame-based and the sequence of Ethernet frames is main- 
tained. 

[0056] Here is a more detailed description of the proposed Ethernet hitless protection solution, having further refer- 
50 ence to Figs. 1 and 4. 

[0057] Every time an Ethernet frame is received at AP #0 of NE #0 it is stored in a queue of incoming messages. 
[0058] Each frame is labeled in order to recover the exact frame sequence at the ending point. For instance, a 
sequence of labeled received frames could be FR 1; FR 2 , FR 3 , ... FR n . 

[0059] The received frame is transmitted by two separate transmitters, TXA and TXB, to Circuit A and Circuit B, 
55 respectively. Different types of Virtual Containers (VC-1 2 for Circuit A and VC-3A/C-1 2 for Circuit B) perform the trans- 
port of a frame along different routes (direct for Circuit A, with an intermediate node for Circuit B). Atthe receiving node 
two different receivers are provided (RXA, RXB). 

[0060] At intermediate node (NE #4) of Circuit B, the Ethernet frames are stored in an intermediate node queue. In 
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principle, the presence of an intermediate node in a Circuit results in a delay in the frame transmission. In the present 
case, Circuit B is faster than Circuit A because the capability of the two pipes (one VC-3 and ten VC-1 2) of Circuit B 
is higher notwithstanding the presence of the intermediate node (NE #4). 

[0061] This means that a frame (for instance FR.,) from Circuit B is received at NE #1 before the same frame is 
5 received from Circuit A; NE #1 just selects the first received one and stores it in a queue of outgoing Ethernet frames 
that are transmitted at AP #1 . 

[0062] Until both the Circuits are active, only the frames received from the faster one are selected and stored in the 
queue of outgoing frames; of course the frame sequence is maintained (possibly it is recovered through the label). 
[0063] If a failure occurs on Circuit B, after the transmission of frame FR 3 , NE #1 receives frame FR 4 only once (only 
10 from Circuit A). 

[0064] NE #1 selects frame FR 4 from Circuit A because it is the first received one and stores it in the queue; the 
same for the following frames until Circuit B is restored. 

[0065] Frame FR 4 and the following ones are not lost and the frame sequence is maintained; this means that a hitless 

protection was successfully performed. 
15 [0066] When Circuit B is restored, NE #1 changes again its selection into a failure-free hitless mode. 

[0067] It is important to note that the Circuit selection is frame-by-frame based and it is not related neither to the last 

selection nor to the reception status of the previous or the following frames. In other words, when a frame labeled as 

FR n+1 is received, the Circuit selection is performed independently of the last selection and also independently whether 

frame FR n or FR n+2 has already been received or not. 
20 [0068] Anyway, the reception of frame FR n+1 before frame FR n could occur when the skew between the two Circuits 

is equal to or longer than the time required for a frame transport or the faster Circuit is restored after a failure. 

[0069] It could happen that the transport of frame FR n is performed by Circuit A only because of the failure of Circuit 

B but the transport of frame FR n+1 is performed by both Circuits because Circuit B has been restored. Due to the skew 

between the two Circuits, NE #1 receives frame FR n+1 from Circuit B before frame FR n from Circuit A. Frame FR n+1 
25 is stored in the queue and the related selection is Circuit B; also frame FR n is stored in the queue but the related 

selection is Circuit A. Of course, frame FR n+1 cannot be provided to AP #1 until the reception of frame FR n . 

[0070] The independent frame-by-frame selection of the Circuit is important not only when a Circuit failure occurs/ 

disappears but also when both the Circuits are active. 

[0071] With reference again to Fig. 1 , let consider a further Link, the Link AP #0 - AP #4; one Circuit of this Link 
30 (Circuit C) could be made up by a VC-3 between NE#0 and NE#4 and a VC-3 between NE #4 and NE #3. It is realized 
that the first VC-3 is the same VC-3 used for Circuit B of Link AP #0 - AP #1 , i.e. it is a shared resource. 
[0072] The above results in a transport delay of a frame along Circuit B that also depends on the traffic of the other 
Circuit (Circuit C) and that can dynamically change. 

[0073] In case Circuits A, B and C are active and the transport delay along one or both Circuits dynamically changes 
35 for the shared resources, the fastest Circuit can dynamically move from Circuit A to Circuit B and vice versa. Thus, the 
Circuit selection can change also without the occurrence of any failures. 

[0074] The present invention can be implemented both in hardware and software. Advantageously it is hardware 
implemented through a SDH/SONET network comprising network elements (for instance ADMs and Cross-Connects) 
and fiber connections. In particular, the new layer according to the invention is provided by a network manager managing 
40 the phisical network at an high level. Furthermore, within the network elements (or at least a part thereof) iat least an 
additional board is provided. Each additional board comprises at least one Ethernet interface, namely an Access Point. 
Generally, a number of Access Points are provided in each additional board. 

[0075] According to a preferred embodiment of the present invention, each additional board comprises FPGA means 
(two FPGAs, namely two Field Programmable Gate Arrays), memory means and lintegrated Circuit means (two ASICs). 
45 The network manager provides some information to the additional board (particularly to the FPGAs) comprising which 
AP should be used, the bit rate of the Ethernet flow (10 or 100 Mb/s) and the SDH/SONET resources to be used for 
transporting the Ethernet signal. Furthermore, the FPGAs perform several additional tasks such as filling/emptying the 
virtual containers. 

[0076] The memory means comprise several memories, namely a data memory, an external memory with routing 
50 information, a link memory for storing information about each link and a circuit memory for containing the circuit queues 
and lables. 

[0077] A further advantage that is provided by the present invention is that each GFP packet for Ethernet frames 
comprises a Core Header Error Check field containing a CRC error correction code for protecting the integrity of GFP 
packet core header. The CRC error correction code according to the present invention is able to correct a single error 
55 and to detect any possible further errors. Thus, the advantage is that only the errored Ethernet frames could be dis- 
carded when a SDH/SONET frame is received, the error-free frames could be advantageously kept. This is in contrast 
with the error correction code mechanisms that are provided for correcting errors in the whole SDH/SONET frame. 
[0078] A still further advantage of the present invention is that it could be applied to any network topology, namely 
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linear, meshed, ring, tree... 



Claims 

5 

1. A method for handling Ethernet frame signals in a SDH/SONET network, the SDH/SONET network comprising 
network elements or nodes and fiber connections connecting the network elements, the method being character- 
ized by the step of defining a new layer/network (NETS) over the SDH/SONET network in order to manage the 
Ethernet signals overthe SDH/SONET network, the new layer/network (NETS) usingthe resources of SDH/SONET 
10 network in such a way as to optimize the provided services and the performances with reference to this specific 

type of transport, wherein the step of defining a new layer/network (NETS) comprises the steps of: 

defining at least two Ethernet Access Points (AP), namely Ethernet interfaces at the SDH/SONET network 
boundary where the Ethernet signals can access/leave the SDH/SONET network; 
15 defining a Link as a pair of Ethernet Access Points providing a point-to-point connection; 

for any pair of Ethernet Access Points, defining corresponding Circuits, namely all the possible routes con- 
necting the pair of Access Points through the SDH/SONET network; and 
dividing each Circuit into Pipes, namely a sequence of smaller segments. 

20 2. Method according to claim 1 , characterized in that it further comprises the steps of: 

e) receiving the Ethernet frame signals at the Ethernet interface of one Access Point (AP); 

f) routing the Ethernet frame signals to at least one link; 

g) selecting one of the available Circuits; 

25 h) selecting one available Path of the first Pipe of the selected Circuit; 

i) encapsulating the Ethernet frame signals into at least one Virtual Containers of the selected available Path ; 
j) transporting the Ethernet frame signals to the next Network Element namely, up to the end of the Pipe; and 
k) at the Ethernet interface of the destination Access Point, extracting the Ethernet frame signals from the at 
least one Virtual Container. 

30 

3. Method according to claim 2, characterized by comprising the additional step of inserting the extracted Ethernet 
frame in a re-ordered queue. 

4. Method according to claim 2, characterized in that, in case the selected Circuit comprises further Pipes, steps 
35 h) to i) are repeated in any intermediate Network Element until the last Network Element is reached. 

5. Method according to claim 2, characterized in that step i) comprises the step of mapping the Ethernet frame 
signals into GFP frames and mapping the GFP frames into Virtual Containers. 

40 6. Method according to claim 2, characterized in that step i) comprises the step of providing a scout message 
containing monitor information for managing the new layer/network (NETS). 

7. Method according to claim 2, characterized in that step j) comprises the step of transporting the same Ethernet 
frame signals through at last two different Circuits and step k) comprises the step of performing a hitless frame- 

45 based switch in order to select frames from the faster Circuit or from the non failured Circuit. 

8. Network manager for managing a SDH/SONET network and handling Ethernet frame signals therein, the SDH/ 
SONET network comprising network elements or nodes and fiber connections connecting the network elements, 
the manager being characterized by providing a new layer/network (NETS) over the SDH/SONET network in 

50 order to manage the Ethernet signals over the SDH/SONET network, the new layer/network (NETS) using the 

resources of SDH network in such a way as to optimize the provided services and the performances with reference 
to this specific type of transport, wherein the step of providing a new layer/network (NETS) comprises: 

defining at least two Ethernet Access Points (AP), namely Ethernet interfaces at the SDH/SONET network 
55 boundary where the Ethernet signals can access/leave the SDH/SONET network; 

defining a Link as a pair of Ethernet Access Points providing a point-to-point connection; 
for any pair of Ethernet Access Points, defining corresponding Circuits, namely all the possible routes con- 
necting the pair of Access Points through the SDH/SONET network; and 
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dividing each Circuit into Pipes, namely a sequence of smaller segments. 



. Device for handling Ethernet frame signals in a SDH/SONET network, the SDH/SONET network comprising net- 
work elements or nodes and fiber connections connecting the network elements, characterised in that it com- 
prises: 

at least one access point (AP) interface for receiving Ethernet frame signals; 

means for routing the received Ethernet frame signals to at least one link, wherein a link is a pair of Ethernet 
Access Points providing a point-to-point connection in the network; 

means for selecting an available Circuit, wherein a Circuit is one of the possible routes connecting the pair of 
Access Points through the network; and 

means for encapsualting the Ethernet frame signals into at least one Virtual Container of the selected available 
Path. 



0. Device according to claim 9, characterised in that it further comprises means for estracting the Ethernet frame 
signals, transported through the network, from the at least one Virtual Container. 

1. Device according to claim 9, characterised in that it further comprises memory means for storing the Ethernet 
frame signals in signal queues. 

2. Device according to any claims 9-11 , characterized in that it comprises means for handling information received 
by a network manager, such information comprising indications of access points to be used, bit rate of incoming 
Ethernet frames and resources to be associated to a certain access point. 
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